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(57) Abstract: The present invention provides a system for creating an application software environment without changing an 
operating system of a client computer, the system comprising an operating system abstraction and protection layer, wherein said 
abstraction and protection layer is interposed between a running software application and said operating system, whereby a virtual 
environment in which an application may run is provided and application level interactions are substantially removed. Preferably, 
any changes directly to the operating system are selectively made within the context of the running application and the abstraction 
and protection layer dynamically changes the virtual environment according to administrative settings. Additionally, in certain em- 
bodiments, the system continually monitors the use of shared system resources and acts as a service to apply and remove changes 
to system components. The present thus invention defines an "Operating System Guard." These components cover the protection 
semantics required by DLLs and other shared library code as well as system device drivers, fonts, registries and other configuration 
items, files, and environment variables. 
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OPERATING SYSTEM ABSTRACTION AND PROTECTION LAYER 



This applicatioa is a continuatioa-in-pait of U.S. Patent .Applicatum No. 
09/456>181 , the entirety of which is incoxpoioted hereiia by reference as if fiiUy 



set forth. 



The present invention relates to coniputer software, and more particularly to 
operating system software. 



BACKGROUND OF THE INVENTION 



In many environrnents, but paiticularly in environments wh^e an application is 
delivered via a network^ the most in^ortant feature is an ability to run applications on the fly, 
without a conoplex installatioit Typically, in ceitain prior art systems, great pains were taken 
to modify a dient system to appear as if a program was installed, or to actually install the 
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applications^ 



complexity of the bade out process require an q)plicadon to be put throu^ a rigoroxis process 
to ensure all of its modifications can be accounted for, and the use of diared files and system 
con^onents by mutt^le applications con^licates back out and the instaUation process. . 
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SDIMMARY OF TBDB INVENTION 



The present invention provides a system for creadag an application software 
environment without changing an operating ^em of a client cono^uter, the system 

• ■ 

conoqprising an operating system abstraction and protection layer, wherein said abstraction 
and protection layer is interposed between a running software application and said 
operating system, whereby a virtual environment in which an application may run is 
provided and q)pUcatiQn level iMeractions are substantiaUyrerooved. Preferably^ any 
changes dkectly to the operating system are selectively made within the context of the 
running appUcation and the abstraction and protection layer dynamically changes the 
virtual environment according to administrative settings. Additionally, in certain 
embodiments, the system continually monitors the use of shared system resources and 
acts as a service to apply and remove changes to system conoponents. 



Thus, for e7sanq>le, ia embodiments wxthin Windows-based operating systems, 
and wherem all operations to the Windows Begistry are tiuough the Win32 API, the 
system preferably provides a means for hookmg fimctions, whereby each time said 
functions are invoked another function or application intercq)ts the call, and the system 
most preferably hooks each appropriate API fimction to service a request whether made 
by an application run fiom a server or if made by an application against a configuration 
key being actively managed 



In other preferred embodiments of the present invention, additional functionality 



protection layer manages the integration of multqile instances of an application by 
recogaizing how many instances of an application are running, and in such embodiments 
most preferably it also avoids making changes on startup and shutdown unless there is 
only one ^plication instance running. In this embodiment it is also possible to support 
muhi-us^r operating systems in which nmltiple instances of an application can be running 
on behalf of different users. 
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Ilms» ihe operating system abstraction and protection layer presents an 
environment to an appfication that appears to be an installation enviromnent without 
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settings are brought into a virtual environment at the time the application runs. Or in the 
case of an installed application, act^ to dynamically ntiodify the behavior of the 
application at mn4ime. Preferred embodJmmts provide a means for preventing 
information on the client coiq)uter £:om interfering or modifying the behavior of an 
application, and most preferably provide a means for dynamically changing the virtual 
environment according to administrative settings. As mentioned above, in certam 
embodiments it will be possible to have more than one instance of a single software 
application running on the same client coicpnter, even if it was not origmally authored to 
do. so. Lx such embodiments, shared, controlled contexts are provided in\|duch at least 
two of said iostances of a single application share one or noore virtual settmgs. 



BKtEF D£SCR]fTION OF THE DRAWBVGS 

HG. 1 is a block diagram schematic showing the relative relationshq) of the present 
invention, an operating system and a software application; 

HG. 2 is a block diagram schematic lowing 

HG. 3 is ablock diagram schenoatic showing 

HG. 4 is a 1)bGfc diagram sciieimtio sturcvii^ 

SETAiLJEID DESCRimON OF THE FBEEXaEO^ 

■ 

Ke&mng now to HG. 1, there is iUostrated a block diagram schematic showing the 
relative relationship of the.present invention, an operating system apd a software application. 
Preferred embodiments of the present invention provide an operating system abstraction and 
protection layer 100 denommated an ^"Operating System Guard." fiitemally, many operating 
systems 10 provide &uk domains to protect applications 50 firom affecting each other when 
run. However, shared system resources and many other operating system features allow this 
protection domain to be con:q)romised. An operatmg system abstraction and protection layer 
100 wiU provide an additional, programmatically contmHed banier between applications 50 to 
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remove most appHcatioii level interactions. Disposed between fhe application SO and operatiiig 
system 10 fixe qpeiating system abstraction and protection layer 100 selectively allows 
changes diiectly to fhe operating system 10^ versos containing the change within tiie context of 
the naming application. For one example, in Window^based systems, all operations to the 
Windows Registry are typically done fhrou^ the Wia32 API As explained below, system 
fimcdons like QoeryRegEx and GetSrofileStnng can be hooked so that each time they are 
invoked, another fimction or application intercepts the call The Operating System Guard 100 
of tiie present invention will book eadi ^ropriate API fimction to service the request, if 
made by an appEcation being actively managed or if made by an ^plication against a 
configuration item being actively managed. In this way, xasloss e;qplicitiy configured to do so, 
the present invention can create die application environment without making any actual 
changes to the end-user's system Also, any modifications made at run-time by the 
application can be persisted or removed easily. 

As used herdn tiie term ^'Operating System Guard" defines a layer between a 

* 

nnming application and fhe operating system of a target computer or client computer that 
provides a virtual environment in wlm^ This virtual 

environment bas several purposes. First, it prevents a running application fi:om making 
cbanges to the client con^uter. If an application atteicpts to change underlying operating 
system settings of a client conq)uter, such settings are protected and only 'Wde" in the 
virtual environment. For exanq)le, if an application attempts to change the version of a 
shared object like MSVCRT JDLL, this change is localized to the application and the code 
resident on the client computer is left xmtouched. 

Second, the invention presents an environment to a running application that 
appears to be an installation environment witiiout performing an installation, and is thus a 
'^seudo installation" or '^stallation-like.'' All of the settings are brought into a virtual 
environment at the time tiie application being served runs, or just-in-time wben the 
application needs the particular setting. For example, if a conoputer program such as 
Adobe Photoshop® expects to see a set of Windows Registry entries under 
HKEY j:.OCAL3IACHENE\Software\A and they are not there on tiie client 

■ * 
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coixqpiiter since Piiotosliop was never installed, a system made in accordance with this 
aspect of the present invention will ^^show" those registry entries to the Photoshop 
programming code exactly as if they were resident on the client conoputer. 

Nbxt, the invention prevents mfonnation that may exist on the client/asers • 
machine from interfering with or modifying the behavior of an applicatiott For exarcple, 
if the user has akeady existing re^stry entries under: 

HKEYj:OCAL_.MAanNE\Software\Adobe 
for an older version of Photoshop, but now wishes to operate a newer version, these 
entries can be hidden firomthe new application to prevent conflicts: 

Finally, the present invention unlocks application behavior that may not exist as 
the application is currently written. It does this through the ability to dynamically change 
the virtual environment accordiog to administrative settings. For exanqple, in a typical 
instance of an enterprise software application, a client application may expect to read a 
setdng for the address of the database to which the user should connect fiom a setting in 

■ 

the registry. Because this registry key is often stored in HKEYJLOCALJSIACHINE, the 
setting is global fox the entire client con^uter. A user can only connect to one database 
without reinstalling the client, or knowtag how to modify this registry key, and doing so 
each time tiiey wish to run the apphcatioiL However, by in^lemwting the present 
-invention, two instances of the application may. now run on the same client con^uter, 
each connecting to a different database. 



CONTEXTS 

In providing this ftmctionahty, each application is able to run in a private context 
within the system. To the application, it has its own private view ofwhat the system 
looks like and its behavior. The present invention provides this by its inherent nature. 
Kefetring to FIG. 2, two separate applications 52,54, or two instances of the same 
application (50 illustrated in HG. 1), can be provided private contexts in which they will 
appear to have separate or difEcring copies of system services, configuration and data. In 
the preferred embodiment, this is the de&ult behavior of the system. 
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By exteading this caacq)t, the Operating System Guard 100 of the present 
iov^ation caxi also pzovide shared, controlled contexts in which two or more applications 
52,54 can share some or all of their virtual sitings. This is impoitant for application 
suites such as IVGcrosofi Office, or for applications that perform, differently in the 
presence of oth^ appfications. For exan^le, many applications use Microsofi Word as 
aa engme &r doing Mail Merge or document creatbn fimctionafity. The applicatidn 
must know about the installation or presence of Word and be able to tap into its 

■ 

functions. In the preferred embodiment, two instances of the same application will share 
a smgle context by default, while two separate applications will maintain private 
contexts. Referring to HG. 3, the two applications S2,S4 can run while the Operating 
System Guard 100 provides a shared view of the available system resources. 

)£SIGN 

As iUustrated in fIG. 4, the Operating System Guard is conq>rised of the 
bllowing subsystems: core 102, configuration manager 104, file manager 106, shared 
object manager 108, device manager 110, font manager 112, process nunag^ 120, 
irocess environment manager 114, loader 116, and recovery manager 118. \^^the 
xception of the core 102, the process manager 120, and the loader 116, aU other 

R * 

ubsystems are elements of the Vhtualization System described in fiirther detail below. 

[he core 102 is primarily respon^le for managing applications and their context as 

* • 

lefined by the configuration files. 

The process manager 120 provided by the Operating System Guard allows the 
(Oie 102 to be informed of any process or thread event that may be of interest ft also 
provides an abstraction layer to the operating system-dependent implementations for 
aanaging a process space and handling thread processing. Processes may be grouped 
ogether into application bundles. An application bundle is a group of processes which all 
hare their virtual resources with each other. f!or example, Microsofi Word and Microsofi 
sxcel may want to share the virtual registry and virtual file system to be able to work 
ogether as an application suite. The process manager 120 calls these application bundles 
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"applications"'. The information about an application exists until the process manager 120 
is told to release the application. If another process needs to be loaded into the application 
bundle, it may do so as long as the application has not been released. 

The loader subsystem 116 of the present invention is used to allow virtual 
environments to be transfecred into and out of the runoing system. Each of the 
Virtualization Subsystems is capable of serializuig its configuration for the loader 1 16, 
and retrievmg it through the reverse process. In addition, the loader 116 is capable of 
staged loading/unloading and combinmg the results of individual stages into one single 
enviroiunent desciiption. 



REGISTRY AISD CONFIGURATION 

Applications require varying amounts of configuration information to operate 

propedy. Atiywhere fiom zero to thousands of configuration records exist for vAddx an 

application can read its configuration On Windows, &ere are two common places for 

configuration inJformation, the Windows Registry and system level iioitialLzation files 

« 

win.h]i and systeuLini in addition, the \WIbQDOWS\SYSTEM directory is a common . 
place for applications to write application specific configuration or initialization files* 
Applications wUl also use configuration or data files in their local application dnectones 
to store additional configuration information. Often this infi^rmation is diScuIt to deal 
widi, as it is in a proprietary format. On platforms other than Windows, there is no 
equivalent of the Registry, but common directories exist for configuration information. X 
Windows has an app-defaults directory. Macmtosh has the System Folder, and other 
operating systems will have corresponding elements. It is important to note that on most 
UNIX systems, each individual application 32,54 will most often store its own 
configuration 152,134 locally, as seen in FIG. 2. 











Till 









component, which wiU provide a fiiU fimction registry to an application, but prevent 
modification to the underlying system registry. All Iceys that an application expects to 
accesswillbepresent,butmay only exist in the virtual registry. In this way, the 
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Opexatmg System Guard 100 of the present invention and the Windows Registry form a 
two-stage process for accessing the registry. If an application needs access to a key, it 
will query the Registry. The Operating System Guard will respond with the key and its 
vahxe if it laiows it. Otherwise, it will.aflow the request to pass through to the Windows 
Registiy. If an atten^t is made to modify the value, the Operating System Guard will 
allow the modification to occur to itself only. The next time the application accesses the 
key, it will be present in the Operating System Guard and the request wiU not flow 
through to the real Registry, leaving it untouched 

The keys that the Operating System Guard uses are specified in three separate 
sections. These Operating System Guard keys are specified as commands in these 
sections to modify an eTdsting key, delete the presence of a key, or add a new key to the 
registry. Inthisway, the virtual registry can appear exactly as the system intends. This is 
iiKq>ortant as the presence or absence of a key can be as io^oitant as the actual value of 
the key. 

In the preferred embodiment, the Operating System Guard first loads a data file 
that contains basic registiy entries for the application. Then a second data file is loaded 
that contains the user's preferences. Finally, the Operating System Guard can optionally 
load a set of keys that include policy items that the user is not allowed to ovenide. The 
three files load on top of each other with duplicate items in each file overriding items in 
the file before it The first time a user runs an application, the second data file will not 
exist because there will be no nser-i^ecific information, only application de&ults. After 
each session, thougih, the Operating System Guard will save the user's changes, 
generating that second data file for use in fiiture sessions. 

Configuration files can be modified in two ways. First, the file can be edited 
directly by an application. In this scenario, the Operating System Guard File subsystem 
described below will address the modification made to the file. Second, in the preferred 
embodiment, an application can call the \^dows API &mily of caUs GetPiofileString, 
WnteProfiOleStrmg, or others to modify these files. In this case, the Operating System 
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Guard of tbe present mveDti0a perfbims exactly as described above interceptmg these 
calls and searvicing them firom within. 

SHAS£P OBJ£CrS 

Many cotiq)onQJ3ts used by operating syst^ns and running applications are shared 

• > 

across several applications ox instances. In general, this is a very good idea. K saves disk 
space, not lequiiing many copies of the same file. It also provides the ability &r 
operating system vendors and third parties to create and distribute libraries of cotomonly 
used code. On the Windows platform. Dynamic Link Libraries, DLLs, are often shared 
within and across applications. On other platforms, the problem is the same. On the 
Madntosh, INTIs and oth^ system conq^onents are loaded for applications. These 
coniponents can have many versions, of which only one is used at a time. QnXJNDC 
systems, dynamic shared objects, e.g., '^so'* library files, axe used by applications to 
speed load time, save disk space, and for other reasons. Many programs use the de&ult 
'libcso." However, this library file is typically a symibolic fink to some version of itself 
such as Ubc.so.3. In practice, this feature has created havoc. These shared con^onents 
have ofien gone through revi^on, with many versions of the same component available to 
be installed. Appfication authors bave found their soflware to work whb potentially only 
one or some of the versions of the shared conq^onent. Thus, in practice, applications 
typically install the version they desire, overwriting other present versions. This 
potentially causes de&ults in other applications ruiming on a system 

On Windows 98, Windows 2000, Microsoft has created the Windows Protected 
FUe System (WPFS)-to allow system administrators to create a file called 

m 

XXXX.LOCAL in the base directory of an application, where XXXX is the executable ^ 
file name without the extension. This causes the Windows Loader to alter its method of 
resolving path references during Loadlibrary executions. This, however, is not sufficient 
to conq)letely solve the problem. First, setting itp the XXXX file is left to the knowledge 
of the system administrator, vMok varies widely. Second, a conq)onent version must 
nndergo a rewmd back to the original, then install this con]ponent in the local dkectory, 
and then create the ".LOCAL" file. This is not a straightforward process for any but the 
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most basic co]]q)Qnents placed in WI^^OWS\SYSIiE^l Also, this solution does not 
cover all of the needed functionality. During LoadLibraty, Windows uses difierent path 
resolution semantics depending on \)\diether the con^qponent was resolved as a resuk of an 
explicit or unplidt LoadUbrary^ .and also Aether a Registry Key exists indicating that it 
is a named, or. well-known^ DLL in this case, the LoadLibrary call will always resolve 
to (he WINDOWS\SYSTEM directory. 

DLLs and other diared conroonents also retain reference count semantics to 
ensure that a conqponent is not touched unless no nxtming applications refer to it. in 
practice, only applications from the operating system vendor and the operating system 
itself have done a good job of obeying this protocol 

As a general rule, it is desired to have a shared object always resolve to the 
correct coiq)onent. To provide this fimctionality it is xeguired to understand the version 
of a component, or range of versions, that an application is able to function with. Then, 
vAi&x the application is to be run, the present invention should ensure that the conq)onent 
is resolved correctly, it is accq)table, in the present invention, to automate the use of 
WPFS or other operating system provided capability, if desired. In this case, it is 
necessary to detect needed con:ponents and place them in the local file system This is 
more cbn^lex than just watching installation, as an installation program will often not 
install a coixy)onent if the required one is aheady there. 

It is desired to identify a method to ensure that named objects are also loaded 
correctly. On the Windows platform, MSVCRT.DLL is a significant culprit within this 
problem area. If multiple versioiis of this object are maintained, the aforementioned 
Registry key can be dynamically changed, allowing the LoadLibrary fimction to resolve 
the correct conq)onent versioiL Another reasonable method of ensuring correa 
con^onent loading is the dynamic editing of a process environment to use a valid search 
path. This search path will ensure that a local corqionent is resolved before a system 
wide conq>on6nt Another possible method for resolution of the correct shared object is 
thioug^ the use of symbolic Imks. A symbolic link caa be made for a shared component. 
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vAUii is resolved at lun-tune by the con^uter^s file system to fhe needed con^onent. 
Finally, the actual open/read/close requests for information from a shared object's file 
can be intercq)tedby the present invention and responded to dynamically for the coccect 
verdon of the file which may exist on the local system or within the invention's 
subsystems. 

Several special &>im exist. On the Windows platfbim, OLE, ODBC, MDXc» . . . 
as wen as a number of other vendor specific conq^onents, are written to be shared 
globally among several or all running processes. la the case of OLE, going as far as 
sharing data and memoiy space between separate processes. OLE prevents more than 
one copy of itself running at a time, as do many of these conipon^ts. OLE also has 
many bugs and features requiring a specific version to be loaded for a specific 
application. In the present invention, an application is able to load whatever version of 
OLE is required, still enabling the shared semantics with other components using the 
same version of OLE. 

In general, unless ^ecifically configured as such, shared objects shoxild be loaded 
privately to ensure conflict prevention. Nothing about the method used to allow a 
conq>onent to be loaded privately should prevent it fcombemg unloaded cleanly or 
correctly loading for another software application, whether being actively m£maged by 
the Operating System Guard or not. In addition, if the system crashes it is required to 
recover fi:om this crash to a clean state, not having overwritten or modified the 
underlying operating system. 

EDLES 

Many applications nse data files within the application to store configuration 

i 

^tries or other application data. The present invention provides a virtual file system 
much like the virtual registry described above. Before the application starts, the present 

■ 

invention can load a list of file system changes, indudmg files to hide and files to add to 
the virtual environment or files to redirect to another within the virtual environment. 
Whenever .the application accesses or modifies any files, the Opeiatmg System Guard 
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checks if the file nmst be redireaed, and if so, in the prefeaed embodiment redirects the 

« 

request to a location specified in the Operating System Guard configuratioiL 



If an application tries to create a new file or open an existing file for wxiting on a 
user's local drive, the Operating System Guard noust ensure that the file is actually 
created or modified in the redirected location. If the application is reloaded at a later time^ 
this file mapping must be reloaded into the Operating System Guard virtual enviromnent. 
When the request is to modify an existing file, which resides on. a user^s local drive, the 
Operating System Guard naaist copy the file in question to the redirection point before 
continuing with the request. The redirected files may not be of the same nanae as the 
original file to ensure safe mapping of file paths, in the preferred embodiment, INI files 
are handled in this way to offer maximum system security while allowing maximum 
application couq)atibility. 

The present invention is particularly iisefiil for applications delivered over a 
network In such in^lementations it is important to understand that software ^plications 
are made p{ several kmds of data, where the bulk of the files a software application uses 
are most preferably mounted on a separate logical drive. Configuration, including both 

# 

file based and registry based, can be user specific and system wide. The application 
delivery system used should mark each file for which of these types any file is. This 
information provides hints to the Operating System Guard system to act on appropriately. 

* 

D£VICE DRIVERS 

Many applications use device drivers or other operating system, level software to 
. implement some of its fimctions such as hardware support or low leve;l interactions 
directly with the operating system. In the present invention, the Operating System Guard 
will provide the capability of dynamically, and as possible privately, adding and 
removing these con^oiients to an application's virtual ^vironment. 

Many device drivers are built to be dynamically loadable. If * at all possible, it is 
the preferred embodiment to load all device drivers dynamically. If a device driver 
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requires static load at boot time, the user imst be presented with this knowledge before 
running tiie ^plication. Once the system has rebooted, the application should continue 
from where it left off However, a laige percentage of device drivers are not dynamically 
unloadable. Although it is preferred to dynamically nnload the driver, if this cannot be 
acconqplished the driver will be marked for removal on the next reboot, and the user 
s^iould be made aware of this. If the application is nm a second time be&re the next 
reboot, the system shouM remain aware of the pres^ce of the driver and not atten^t a 
second installation, waiting for tenmnation to rmiark the con^onent removable at next 
reboot 

It is important to characterize the base sLmilarities and differences, as they exist 
for each device driver class, to ensure the present invention can correctly function. It is 
not truly desired to load and imload device drivers &r system hardware that is constantly 
present. . It should be understood that although tbis is not a preferred embodiment 'in 
terms of programming ease, it is wothin the scope of the present invention and may be 
required for specific reasons, such as the restriction in licensing agreements for 
applications that are delivered and run usmg the present invention. 

On non-Microsofi platforms^ device drivers are typically handled very differently. 
Macintosh systems si^poit both static and dynamic drivers, but they are all installed and 
removed through the same method. Linking with the Macintosh system folder will 
provide the necessary support. For UNIX systems, device drivers most typically require 

■ 

B modification to the running UNIX kernel, followed by a reboot. This process can be 
very complex. In the preferred embodiment, this process is automated; including 
resettkg the kernel once the application is conq>let6. The general parameters of the 
process are the same as that described above for Windows applications, the actual process 
steps of con^ilation and persons familiar with such operating systems can carry out 
reboot 
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Finally^ those of skill in the art yM imderstand that it is deshrable to be able to 
recover and remove diivers across system &ilure& Whatever data or processes necessary 
to retain system integrity are therefore a preferred embodiment of the present invention. 
Those of skill in the art will also appreciate that all types of device drivers might not be 
conveniently or efiGLciently provided via the present invention, most particularly those 
associated with permanent hardware attached devices. 

OTHER ITEMS 

In the present invention, it is recognized that there are several conq>onents of the 
invention, the behavior or presence of which is different on alternate operating systems. 
These conoponents include fonts, processes, environment variables, and others. 

Some applications require fonts to be installed in order to perform, correctly. Any 
fonts required will be specified in the Operating System Guard's configuration file. The 
Operating System Guard wiU enable these fonts prior to running the appfication and if 
necessary remove tiiem afterwards. Most systems bave a common area &r storage of 
fonts in addition to a process for registering them or noaldng the system aware of their 
presence, the Operating System Guard wiU utilize these available methods. 

* 

On Windows^ a font is copied to the VWINDOWS\FONTS directory. This 
however does not guarantee that llie font is available to the running program. In the 
preferred embodiment, if the program uses the Windows API to access fonts, the font will 
need to be registered with a Win32 API call such as CreateScalableFontResource/ . 
AddFontResom:ce. This will insert the font into the system font table. Once con:Q)lete, 
tbe Operating System Guard can remove the font with anotiier appropriate API call like 

■ 

RemoveFontResource, then remove the file from the system As an alternate .< 
embodimmt, tlie Operating System Guard could book the API fimctions as described in 
the virtual registry m^od. In addition, the Operating System Guard can use its File 
subsystem to. avoid placing the actual font file in tiie running system 

On Madntosh, the process is extremely similar and based on files iii the 
Macmtosh system folder and registration activation. On UNIX, howevCT, the process is 
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dependent upon the application. Most typically, font resources are added to the system as 
regular files resolved in the proper locadon, so they can be accessed by name. With 
many Motif systems, a font desci^tion needs to be placed into a £3nt resource file, wMch 
vASl allow the font to be resolved. The Motif or X application can invoke the font either 
through the resolution subsystem or by a direct call. Recently, many Motif and CDE 
based systems utilize Adobe scalable postsci^t fonts. These fonts need to managed 
through the Adobe type management system. Tliere are exceptions, however, and as 
stated above, there are alternates to the Windo\^ or other pperatmg system de&ult font 
management systems. The Adobe Type Manager provides some alternate inter&ces for 
this process, as do oth^ third party type management systems. ]h most cases it should be 
decided whether to suppott the inter&ce or ignore it. The purpose of Operating System 
Guard is not to provide a universal layer for all these systems, only to do so for the 
operating system's own' subsystem 

Many appUcationsrequire environment variables to* be set This is most common 
. on UNIX systems, but is also beavily used by software, which was otiginaUy wdtten on 
UNIX and ported to the Windows operating systems. Applications on the \^^dows 
operating systems beavily rely on the DOS PATH environment variable and o&&x set 
their own application specific entries. On the Windows Px/Me environments, there are 
many environment settings, whicb are applicable as at its core is the DOS subsystem. If 
an application requires the presence of qiecific variables, or values to be set in existing 

* 

. environment variables, the required environment variables will be specified in the 
Operating System Guard's configuration file. The Operating System Guard will set these 
variables for the application's main process when it is launched. As applications do not 
typically change environment settings as they operate, the virtual environment will not 
trap these calls, nor will it provide the fuU con^lement of functionality that the registry 
and configuration subsystem does. 

RECOVERY 

In some cases shown in the previous sections, actual modifications must be made 
to the operating system. This is fieqoeat "wiili device drivers and fonts. laaddition. 
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changes caa be made to the virtual envtronment that need to be persisted and available 
the next time an application is run. It is required that the Operating System Guard system 
be able to recover fiom changes to the system, removing the change from the system at 
its eadiest possible opportunity. Alternately, ifthe system crashes during an 
application's execution, the Operating System Guard shoidd track enough inJEbrmation to 
remove any change to the system if it is rebooted or otherwise, and should track the 
changes made to the virtual environment. In the preferred embodiment, this is 
implemented as a transacticm log, but can in other embodiments be done as some oth^ 
sbtnilar conoponent, vHnclx can be read on system startip so that changes can be backed 
out 

CONTROLLING VIRTUALIZATION 

An in[q>ortant aspect of the invention relates to control of the many &cets of 
virtualization \^ch the Operatmg System Guard is capable o£ In the preferred 
embodiment there exists an iustrumentation program able to ascertain the correct aspects 
of a software system to control Also included is a method to allow administrators and 
end users to view and modify those items to be virtualized by the systenL 

In the automated program, the application to be controlled is observed in order to 
gauge the a^ccts of control The automated program is capable of performing this task 
during the installation process of the application, during run-time of the application, or a 
combination of both. In the preferred enibodiment, the 0>peratiiig System Guard is 
embedded ia a wrapper 8pplicati.on. Post installation, or after one or many uses of the 
software, the wrapper application will query the Operating System Guard for a detailed 
list of all of its actions. From this list of actions, the wrapper application win create the 
configuration files required to load and operate the Operating System Guard on 
subsequent uses. 

If used as part of the installation process, the Operatinjg System Guard, in the 
preferred embodiment, will act as a virtual layer allowing the installation to be entered 
into its environment only. After the installation, all of the files, settings, et. aL can be 
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dunked for rdoad later. la this way, ike in^allatioii will leave the onginal system intact 
and wiU liave automatically created the necessary configuration files. When used during 
use of the application, the Operating System Guard is able to record ei&er difEerential 
modifiications to the mvkomnent, or recodify the ccmfiguration files. 

The Operating System Guard will pass its information to the wrapper application 

m 

for post-processang. In the preferred embodiment, in addition to.the automiatic entries 
that the system can create, the wrapper application is programmed with operating system 
specific and application or domain specific knowledge. This knowledge is used to alter 
the output of the process to reflect knovm uses of configuration items or other eatdes. In 

m 

the preferred embodiment, a rules-based system is employed to cou^axe observed 
behaviors with known scenarios in order to e£fect changes to the coding. 

The wrapper application is also used as a viewer and/or editor for the 
configuration output of the process. This editor, in the preferred enibodiment, enables a 
system administrator to add, edit, or delete items or groups of items firom the 

■ 

configuration. In observiag the configuration through the editor, the administrator can 
also make replicas of the configuration, changing specific items as needed to effect 
application level or user custom changes 

Referring now to FIG. 1, an embodiment of the present invention is illustrated 
functionally. In this embodiment, two sets of appBcationAiser data 60 are illustrated. 
The Operating System Guard 100 keeps the two instances of the application 50 firom 
interfering with one another. Jxi addition, as e^lained above, the operating system guard 
100 serves as an abstraction layer and as such collects commands and comnounications 
between the application software 50 and the actual operatmg system 10 of the client 
conqputer. As illustrated graphically by the arrows^ certain commands are between the 
Operating System Guard and the software apphcation, this is in distinction to typical 
installations where these conuuands would instead be acted upon by the operating system 
itself Tesulting in changes to the client con^^ter that might not necessanly be wl^at the 
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operator iatended. On the other liand, other commands pass through the Operatiiig 
System Guard and are then transferred to the Operating System itself 

While this invention has been particularly shown and described with references to 
prefeired embodiments Ihereoi^ it will be understood by those skilled in the art that 

■ 

various changes ia form and details may be made therein without departing fiom the 
scope of the invention enconqpassed by the appended claims. 
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What is claimed is: 

1. A system for creatiiig aa appEcation software enviromnent wlthoiit chaiigiiig an 
operatiag system of a cfient con^uter, the system conq)iisiiig an operating system 
abstractioii and protecdon layer, wherein said abstraction and protection layer is 
inteiposed between a nmning software application and said operating system, whereby a 
virtual environment in which an application may run is provided and application level 
kteractions are substantiaUy removed. 

2. The system of claim 1, vdiereiu changes directly to the operating system are 

3 . The system of claim 2, wherein the abstraction and protection layer dynamically 
changes the virtual environment according to administrative settmgs. 

4. The system of claim 1, ^vherein the system continually monitors the use of shared 
system resources and acts as a service to apply and remove changes to system 

4 J 

coxx^onents. 

5. The system of claim 1, ^^em the operating system is a Windows-based operating 
system, and wherein all operations to the Windows Registry and .ini files are through the 
Win32 API, the system fiuther conQ>rismg a means for hooking fimctions, whereby each 
time said fimctions are invoked another fimction or application intercepts the calL 

6. The system of claim 5, wherein the system hooks each appropriate API fimction to 
service a request whether mad^ by an plication run fiom a server or if made by an 
applicatioh against a configuration key being actively managed 

* 

7. The system of claim 1, herein said operating system abstraction and protection layer 
manages the integration of multiple instances of an application by recognizing how.many 
instances of an application are running. 
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8. The system of claim 7^ herein said operating system abstraction and protection layer 
avoids making changes on startiq) and shutdown miless there is only one appfication 

. instance naming. 

9. The system of claim 1, v^erein said operating system abstraction and protection layer 

* I 

presents an environment to an application fhat appears to be an installation enviropment 
witiiout performing an installation, whereby a '*pseudo installation^' is created in which 
all of the settings are brought into a virtual environment at the time tiie application runs. 

10. The system of claim 9, fiirther conqprising a means for preventing information on the 
client computer firom. interfieiing or modifying the behavior of an application. 

11; The system of claim 9, further conqpiising a means for dynamically changing the 
virtual environment according to administrative settings. 

4 

12. The system of claim 9, v^erein more than one instance of a single software 
application runs on the same client conoputer, and wherein eacb of said more than one 
instance connects to a different database 

13. The system of claim 12, wherein shared, controlled contexts are provided in which at 
least two of said instances of a single application share one or more virtual settings. 

14. The system of claim 1, forther conprisiag a device driver monitor that receives 
instmctions at the time of installation for a particular application. 

15. The system of claim 1, fiuther con^rismg a virtual Windows Registry con5)onent to 
provide a fidl function registry to an application, but prevent modification to the 
imderlying system. legistiy. 
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16. The system of daim 1, wherein the operating system ahstiaction and protection layer 
xe^onds with a key and its vahie if said key and value are stored within the operating 
^stem abstraction and protection layer, if not stored, the operating system abstraction 
and protection layer allows the request to pass through to the Windows Registry. 

* « 

17, The system of claim 16, wherein if an attenq>t is made to modify the value of said 
key, the operating system abstraction and protection layer allows the modification to 
occur to itself only. 
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